Cilium Service Mesh: cuando no necesitas sidecars

Cilium empezó como CNI basado en eBPF y evolucionó hasta ser una alternativa completa a service meshes tradicionales — sin sidecars. Su arquitectura aprovecha que eBPF puede hacer policy, observability, y encryption en kernel, sin proxy por pod. Para clusters grandes, el ahorro de recursos es significativo. Istio respondió con Ambient Mode (similar filosofía). Este artículo compara el enfoque sidecarless y cuándo elegir cada uno.

El problema de los sidecars

El modelo sidecar (Linkerd, Istio clásico):

• Un Envoy/linkerd-proxy por pod.
• Overhead de recursos: 50-200MB RAM + CPU por pod.
• Latencia adicional: 2-5ms round-trip.
• Complexity operacional: muchos procesos, lifecycle management.

En clusters con miles de pods, multiplicado por sidecar, es significativo.

El enfoque Cilium

Cilium reemplaza sidecar proxies con:

• eBPF en kernel para policy y encryption simple.
• Envoy centralizado para L7 features complejas (solo donde se usan).
• Hubble para observabilidad nativa.
• Integración CNI — Cilium es tanto CNI como service mesh en una pieza.

El resultado: features comparables con menos overhead.

Features principales

mTLS con eBPF

Cilium puede encriptar tráfico entre nodos con WireGuard (simple y rápido) o IPsec (más compatible). No requiere inyección de sidecars.

# CiliumClusterwideEncryptionPolicy
apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: enforce-encryption
spec:
  endpointSelector: {}
  ingress:
    - fromEntities:
        - cluster

WireGuard por nodo, no por pod. Menos granular que mTLS por servicio pero más eficiente.

L7 policies

Cilium soporta policy a nivel aplicación:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
spec:
  endpointSelector:
    matchLabels:
      app: api
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: "80"
              protocol: TCP
          rules:
            http:
              - method: "GET"
                path: "/api/v1/users"

Para traffic que requiere L7 (HTTP verbs, paths), Cilium arranca un Envoy por nodo (no por pod). Menos overhead.

Hubble: observabilidad

Hubble es la capa de observabilidad de Cilium:

• Flow logs detallados.
• Service dependency maps (quién habla con quién).
• Policy verdicts (por qué un request fue permitido/denegado).
• Integration con Prometheus y Grafana.

Equivalente funcional a Kiali + linkerd-viz pero integrado.

Load balancing

Cilium incluye load balancer kube-proxy-replacement:

• XDP para ingress con throughput masivo.
• Session affinity, health checks.
• BGP integration para anunciar LoadBalancer IPs.

Para clusters grandes, es reemplazo directo de MetalLB + kube-proxy.

Multicluster y service mesh distribuido

Cilium Cluster Mesh conecta múltiples clusters:

• Services accesibles por nombre DNS entre clusters.
• Failover automático entre clusters.
• Policy consistente cross-cluster.

Más simple operativamente que federación Istio.

Cilium vs Istio Ambient

Istio respondió a la crítica de sidecars con Ambient Mode (GA en 2024):

• ztunnel por nodo (L4 + mTLS).
• Waypoint proxy opcional por namespace/cluster para L7.
• Ventaja: sin sidecars, similar a Cilium.

Cilium tiene más camino recorrido en sidecarless. Istio Ambient es más nuevo pero cuenta con el ecosistema maduro de Istio.

Cilium vs Linkerd

Linkerd sigue con sidecars (linkerd2-proxy en Rust):

• Linkerd es más simple de operar pero tiene sidecar overhead (aunque muy ligero).
• Cilium tiene más features pero más complejidad.
• Cilium es también CNI; Linkerd complementa tu CNI.

Para clusters que ya tienen un CNI (Calico, Flannel), migrar a Cilium es paso grande. Para greenfield, Cilium unificado es atractivo.

Resource comparisons

Benchmark orientativo (cluster 100 nodos, 1000 pods):

Números aproximados, dependen mucho de configuración.

Casos reales

Cilium en producción:

• Datadog: replaced iptables-based networking.
• Bell Canada: CNI estándar.
• Sky UK: service mesh en multi-cluster.
• Lyft: considerando migración.
• Google GKE integra Cilium como Dataplane V2.

Adopción mayor en equipos con expertise eBPF.

Limitaciones

Ser honesto sobre Cilium:

• Curva de aprendizaje alta: eBPF, CRDs, tooling específico.
• Kernel compatibility: requiere kernels recientes para mejores features.
• Menos granular identity: encryption por nodo vs por servicio. Para multi-tenant estricto, Istio Ambient con mTLS per-pod-identity es mejor.
• Migración disruptiva: cambiar CNI en cluster existente es proyecto.
• Community más pequeña que Istio.

Cuándo elegir Cilium

Buenos fits:

• Clusters grandes (>500 pods) donde overhead sidecar importa.
• Equipos con experiencia eBPF o dispuestos a invertir.
• Greenfield Kubernetes sin CNI legacy.
• Necesidad de L7 policy con throughput alto.
• Multi-cluster con requisitos de connectivity avanzados.

Cuándo NO Cilium

• Cluster pequeño donde sidecars no son problema.
• Ya corriendo Istio con features complejas — migrar no compensa.
• Equipo sin experiencia networking low-level.
• Requisitos de identity fina por pod (prefer Istio Ambient).

Ecosistema comercial

Isovalent (empresa detrás de Cilium) fue adquirida por Cisco en 2024, lo que señala validación enterprise pero también potencial vendor push. Alternativa open-source sigue funcionando sin dependencia.

Conclusión

Cilium representa una evolución genuina del service mesh: sidecarless, eBPF-native, integrado con CNI. Para clusters grandes y equipos con capacidad técnica, ofrece ventajas reales en recursos y features. No es el elección correcta para todos — Linkerd sigue siendo válido para simplicidad, Istio clásico para feature-completeness, Istio Ambient como alternativa sidecarless con diferentes trade-offs. La elección del service mesh en 2024 tiene más opciones maduras que nunca; la decisión debe basarse en tu contexto técnico y equipo, no en mode.

Síguenos en jacar.es para más sobre Kubernetes, eBPF y service mesh.